Reject standalone keys with mismatched IDs - #980
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
dahlia
left a comment
dahlia
left a comment
There was a problem hiding this comment.
Before I continue reviewing the implementation, I need a few points clarified and corrected.
The PR description identifies the model as “Codex (GPT-5),” and the commit uses Assisted-by: Codex:gpt-5. GPT-5 is a real model identifier, but it was released nearly a year ago, and the current model family is GPT-5.6. Please check the exact model identifier shown in the Codex session or configuration. If gpt-5 is accurate, please confirm that. If it is not, update the PR description and amend the commit so that both identify the model that was actually used. Please do not replace it with the latest model merely because it is current.
The commit also records both its author and committer as junseok <junseok@junseoks-MacBook-Air.local>, which GitHub cannot associate with your account. Please configure your preferred name and a GitHub-verified email address, or your GitHub-provided noreply address, then amend the commit and force-push it.
Fedify's AI_POLICY.md requires an AI-assisted pull request to be fully verified through human use. The PR description says that you reviewed the change and ran the Deno, Node.js, and Bun checks locally. Before proceeding, I need to confirm both your understanding of the patch and what you personally verified.
Please answer these questions in your own words, without using Codex or any other AI tool (영어가 불편하시면 한국어로 답변하셔도 됩니다).
- Why does accepting a standalone key with a mismatched
idnot allow that key to impersonate another actor? - Why does the patch continue accepting a standalone key without an
id? - Why is the actor branch’s fragmentless single-key tolerance unaffected by this change?
- Why should a rejected mismatched key be negatively cached under the requested URL?
- How did you verify that the regression test fails without the patch?
- Did you personally run and review the results of each listed Deno, Node.js, and Bun check, or were those checks run autonomously by Codex?
Once these points have been addressed, I can continue reviewing the implementation.
Keep fetched key identities aligned with their requested URLs and cache
entries. Add regression coverage for both CryptographicKey and Multikey
rejection and negative caching while preserving
actor lookup behavior.
Fixes fedify-dev#963
Assisted-by: Codex:gpt-5.6-sol
262a160 to
4e7c9a8
Compare
처음에는 key 조회와 actor 소유권 확인이 서로 별개라고 봤습니다. 그런데 doesActorOwnKey()도 key의 ownerId나 id를 사용하
이번 변경에서는 id가 있고 그 값이 요청 URL과 다를 때만 거부합니다. id가 없는 key까지 막으면 기존 동작과의 호환성이 깨
이 경우는 actor 문서 안에서 key를 찾을 때 적용되는 기존 동작입니다. 이번 검사는 standalone key를 직접 가져오는 분기에
캐시는 실제로 요청한 URL을 기준으로 동작합니다. 해당 URL에서 유효한 key를 가져오지 못한 것이므로, 같은 문서를 반복해서
테스트는 그대로 두고 packages/fedify/src/sig/key.ts의 구현 조건만 패치 전 상태로 되돌려 실행했습니다. 그 결과 key:
focused Deno 테스트, 패치 제거·복원 검증, Deno 전체 7개 테스트, check-each 
|
dahlia
left a comment
dahlia
left a comment
There was a problem hiding this comment.
Thank you for the detailed response and for updating the commit. The author and committer identity is now correctly associated with your GitHub account. Your explanation and screenshot of the regression test, together with your explicit confirmation that you personally ran and reviewed the listed checks, answer my questions about human verification.
Two points remain.
First, the commit trailer now says Assisted-by: Codex:gpt-5.6-sol, but the PR description still says “Codex (GPT-5).” Please confirm how you determined that the exact model used was gpt-5.6-sol, rather than inferring it from the current model family, and update the PR description to match.
Second, your answer to the first question conflicts with both the PR description and the reasoning in #963. You wrote that, because doesActorOwnKey() uses the key’s ownerId or id, you could not conclude that the mismatch was unrelated to impersonation.
In the HTTP signature path, doesActorOwnKey() checks ownership in one of two ways. If ownerId is present, it compares that value with the activity’s actor. If ownerId is absent, it fetches the actor and checks whether that actor lists the key’s id. In either case, the mismatch between the requested keyId URL and the returned object’s id is not what establishes the actor–key relationship.
My understanding is therefore that this patch keeps the fetched object’s identity consistent with its lookup and cache key, but does not close an actor impersonation path. That is also what the current PR description says.
If you agree, please clarify your first answer accordingly. If you still believe the mismatch may enable impersonation, please describe a concrete example, including the requested keyId, the returned key’s id and ownerId, the activity’s actor, and the path through doesActorOwnKey() that would accept it. That would materially change the security assessment and scope of this PR.
Please answer this remaining technical point in your own words, without using Codex or any other AI tool.
| @@ -0,0 +1,5 @@ | |||
| - Standalone key documents whose `id` differs from the requested key URL are | |||
| now rejected instead of being cached under the wrong URL. [[#963]] by | |||
| ojspp41 | |||
There was a problem hiding this comment.
- A closing parenthesis is missing.
- You need to put
#980, the number of this pull request as well. - We prefer using real names rather than pseudonyms here. Unless you have any strong preference for a pseudonym, could you please use your real name instead?
2 participants
Background
fetchKey()accepts either an actor document containing keys or a standaloneCryptographicKey/Multikeydocument.The actor branch already checks candidate key IDs against the requested
keyId. The standalone branch previously accepted any object of the requested key class without checking itsid. As a result, a document fetched from one URL could declare a different ID and still be returned and cached under the requested URL.Although this does not let the key impersonate another actor—the owner/controller checks remain responsible for binding a key to an actor—it leaves the fetched key identity inconsistent with its lookup and cache key.
Changes
id, preserving the existing compatibility behavior.idonly when its URL exactly matches the requestedkeyId.iddiffers from the requested URL.@fedify/fedify.Regression coverage
The regression test supplies standalone key documents whose IDs differ from their requested URLs and verifies that:
CryptographicKeyandMultikeydocuments are rejected;{ key: null, cached: false };cached: true.I also confirmed that the new regression test fails against the previous standalone-key behavior and passes with this change.
Existing cache entries
This change validates newly fetched standalone key documents. It does not retroactively validate or evict mismatched key objects that may already exist in a persistent
KeyCachefrom before the upgrade.I kept existing cache-entry handling out of scope because #963 specifically concerns resolving a fetched standalone document, and cache storage and retention are provided by the application. I am happy to add validation or stale-entry handling for cached keys in this PR if the maintainers prefer that behavior.
Testing
The following checks passed locally:
mise exec -- deno test --check --doc --allow-all --unstable-kv --trace-leaks packages/fedify/src/sig/key.test.tsmise run check-each fedifymise run test-each fedify(Deno, Node.js, and Bun)mise run checkFixes #963.
AI usage
Implementation, regression-test drafting, code review, and local verification were assisted by Codex (GPT-5). I reviewed the resulting change and exercised it locally using the Deno, Node.js, and Bun workflows listed above.